昨天(Day 13)談的是那張卡放在哪裡、裡面有什麼欄位、什麼時候被讀進 system prompt。今天往下一層問：description 這欄字串，到底在系統裡扮演什麼角色？

multi-agent 系統的委託對象是怎麼決定的？

我原本以為是查表：維護一份 {"漢堡": "burger_agent", "披薩": "pizza_agent"} 之類的對應，收到請求就查。實際上不是。

orchestrator 把每張 agent card 的 name 與 description 塞進 system prompt，然後由 LLM 讀那段自然語言做條件匹配。路由決策就是一次模型推論。

想一下為什麼會走這條路而不是查表。查表需要有人維護那份對應關係，新增一隻 agent 就要改一次對照表，兩邊還可能不同步。讓 LLM 讀 description 做匹配，省掉了這份對照表，代價是路由品質完全綁在 description 寫得好不好，中間沒有任何人工校對的關卡。這是拿確定性換彈性的典型取捨，我自己還沒看過兩種做法的量化比較，先當推論看待。

所以 description 是執行期行為

把 description 寫壞等於把路由寫壞，而且不會有任何 lint 或 type check 攔你。它在 code review 裡看起來就是一行字串，沒有人會覺得那行需要仔細看。

驗證方法很直接，我列在自己的實驗清單裡：把漢堡店的 description 改成「只賣披薩」重新部署，然後問漢堡。路由就會歪。這個實驗值得每個做 multi-agent 的人跑一次，因為它把「那行字串真的會影響行為」變成親眼看到的事。

另一個看得到的證據

description 進了 system prompt，就代表它會被算進計費裡。orchestrator 第一次呼叫時的 prompt_token_count，裡面含的是所有 agent card 的內容，不是只有這次委託用到的那張。掛的 agent 越多，這個底噪越大，跟這次對話有沒有真的用到那隻 agent 無關。

這件事跟「description 是路由依據」是同一個現象的兩面：它會被讀（影響路由），也會被算錢（影響計費），兩件事同時發生，因為它們發生在同一個地方，就是 system prompt。

同一原理的其他落點

一旦接受「描述欄位就是 prompt」，你會發現這個模式到處都是：

• tool description
• MCP server 的工具說明
• subagent 的 description 欄位
• function calling 的 parameter description

這些欄位全部是 prompt，寫的時候要當成在寫 prompt。 不是在寫給人看的註解。

我自己的習慣改變是：寫這些欄位時不再問「這個東西是什麼」，改問「什麼情況下該選它」。description 一旦被當成執行期行為看待，接下來要問的就是怎麼寫才不會出事，這是明天的主題。